home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Fritz: All Fritz
/
All Fritz.zip
/
All Fritz
/
FILES
/
COMMADIO
/
GT1403_5.LZH
/
GTHOST.DOC
< prev
next >
Wrap
Text File
|
1988-11-01
|
99KB
|
2,311 lines
GT POWER - 14.00
Copyright (c) 1985, 1988: by P & M Software Co.
All rights are reserved.
Host Mode Documentation
April 25, 1988
P & M Software Company
6603 Rookin #386
Houston, Texas 77074
U.S.A.
Voice Phone: (713) 728-4313
Modem Phone: (713) 778-9471
Modem Phone: (713) 772-2090
1
Table of Contents
-----------------------------------------
Brief Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Installation of Host Mode . . . . . . . . . . . . . . . . . . . . . 4
The "Modem Init String" . . . . . . . . . . . . . . . . . . . 4
The "Host Mode: Modem Init String" . . . . . . . . . . . . . . 4
The "Modem Answer String" . . . . . . . . . . . . . . . . . . 5
The "Result Codes" . . . . . . . . . . . . . . . . . . . . . . 5
Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Hang-up during host mode . . . . . . . . . . . . . . . . . . . 5
The "Message base PATH" . . . . . . . . . . . . . . . . . . . 6
The "Default file section" . . . . . . . . . . . . . . . . . . 6
Security Considerations . . . . . . . . . . . . . . . . . . . . . . 7
DSZ.EXE . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
PCKERMIT.EXE . . . . . . . . . . . . . . . . . . . . . . . . . 8
Host Mode Text Files . . . . . . . . . . . . . . . . . . . . . . . 11
Forcing the "More?" prompt . . . . . . . . . . . . . . . . . . 11
Disable the "More?" prompt . . . . . . . . . . . . . . . . . . 11
Disable ^K/^C break . . . . . . . . . . . . . . . . . . . . . 11
ANSI graphics . . . . . . . . . . . . . . . . . . . . . . . . 11
GTSYSID.BBS . . . . . . . . . . . . . . . . . . . . . . . . . 11
GTWELCOM.BBS . . . . . . . . . . . . . . . . . . . . . . . . . 11
GTPASSWD.BBS . . . . . . . . . . . . . . . . . . . . . . . . . 11
GTBULLET.BBS . . . . . . . . . . . . . . . . . . . . . . . . . 14
BULLETx.BBS . . . . . . . . . . . . . . . . . . . . . . . . . 14
GTMENU.BBS . . . . . . . . . . . . . . . . . . . . . . . . . . 15
GTHELP.BBS . . . . . . . . . . . . . . . . . . . . . . . . . . 15
GTBYE.BBS . . . . . . . . . . . . . . . . . . . . . . . . . . 15
GTBYEx.BBS . . . . . . . . . . . . . . . . . . . . . . . . . . 15
GTUSER.BBS . . . . . . . . . . . . . . . . . . . . . . . . . . 15
GTDIR.BBS . . . . . . . . . . . . . . . . . . . . . . . . . . 15
GTDDIR.BBS . . . . . . . . . . . . . . . . . . . . . . . . . . 16
GTBMENU.BBS . . . . . . . . . . . . . . . . . . . . . . . . . 17
GTMDIR.BBS . . . . . . . . . . . . . . . . . . . . . . . . . . 17
GTDOORS.BBS . . . . . . . . . . . . . . . . . . . . . . . . . 18
GTDOORn.BAT . . . . . . . . . . . . . . . . . . . . . . . . . 18
ANSWERn.BBS . . . . . . . . . . . . . . . . . . . . . . . . . 19
QUESTn.BBS . . . . . . . . . . . . . . . . . . . . . . . . . . 19
PQUESTn.BBS . . . . . . . . . . . . . . . . . . . . . . . . . 20
GTQMENU.BBS . . . . . . . . . . . . . . . . . . . . . . . . . 20
PROTOCOL.BBS . . . . . . . . . . . . . . . . . . . . . . . . . 20
WELCOME.BBS . . . . . . . . . . . . . . . . . . . . . . . . . 21
MBULLETx.BBS . . . . . . . . . . . . . . . . . . . . . . . . . 21
SYSOP.BBS . . . . . . . . . . . . . . . . . . . . . . . . . . 21
SCHEDULE.BBS . . . . . . . . . . . . . . . . . . . . . . . . . 22
FILES.BBS . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Host Mode Control Files and Directories . . . . . . . . . . . . . . 24
Running Host Mode . . . . . . . . . . . . . . . . . . . . . . . . . 25
SYSOP COMMANDS . . . . . . . . . . . . . . . . . . . . . . . . 25
Command Line Usage . . . . . . . . . . . . . . . . . . . . . . 25
Host Mode LOG . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
The Shell to DOS . . . . . . . . . . . . . . . . . . . . . . . . . 27
COMMAND.COM . . . . . . . . . . . . . . . . . . . . . . . . . 27
2
DOS 2.xx . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Using the Shell to DOS . . . . . . . . . . . . . . . . . . . . . . 28
Generic Tool Interface . . . . . . . . . . . . . . . . . . . . . . 29
Remote Sysop Interface . . . . . . . . . . . . . . . . . . . . . . 29
Usage of Color . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Logon DOOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Logoff Batch File . . . . . . . . . . . . . . . . . . . . . . . . . 31
APPENDIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
extended ASCII codes . . . . . . . . . . . . . . . . . . . . . 32
sample ANSI sequences . . . . . . . . . . . . . . . . . . . . 32
(tm) DESQview is the trademark of QuarterDeck Office Systems.
3
Brief Summary
-------------
The host mode provided within GT POWER allows you to run an unattended
session with your system. That is, if you expect to receive calls from
other computer systems (say from clients or a set of authorized remote
users) then you can tell GT POWER that it should automatically answer
the telephone for you, verify the caller's credentials, and if found to
be valid, to provide that user with a menu of functions that can be
performed. All of that, of course, without further intervention on your
part.
Security is of paramount importance when running in host mode for
obvious reasons. Please read the section entitled 'Security
Considerations' before attempting to operate this system.
Installation of Host Mode
-------------------------
The most important thing about host mode is proper installation of the
modem control strings and result codes. These strings and codes must
not just control the modem, they MUST WORK TOGETHER. For example, if
the modem init strings specify "verbose" result codes, then the result
code table better have the "verbose" codes in it, not the "terse" codes.
There are 11 specific areas that *must* be installed; all of these
options and strings are accessible via the ALT-I command. Let's discuss
each of these items in turn:
1. The "Modem Init String". The default value is:
AT V1 Q0 E0 X1 S0=0 S2=43|
Assuming that one wants to use the default string, there is really
only one thing that one SHOULD DO to this string: change the Xn
command. The most powerful Xn command available on your modem is
the one to choose. With a USRobotics Courier 2400 modem, use
either X5 or X6. With a normal Hayes-compatible 1200 baud modem,
use X1. X4 would be normal for most Hayes-compatible 2400 baud
modems. For other modems consult the modem manual.
NOTE:
Many so called "Hayes-compatibles" are compatible in name
only. We get many calls for support from individuals with
non-Hayes modems. Please read your modem manual carefully
because it is very hard to support all the different modems.
2. The "Host Mode: Modem Init String". This string is found under
item #30 of the configuration screen. The default value is:
AT V1 Q0 E0 M0 X1 S0=1 S2=255|
There are several things one could do to this string. First, one
must modify the X1 command to match the value added to the Modem
Init String above. Secondly, if one desires the speaker to be
heard during host mode, remove the M0 from the string. Thirdly,
the S0=1 may be changed to S0=0, THIS IS THE ONLY OTHER VALID
4
VALUE! If S0=0 is used, the modem will not answer automatically,
GT will count the rings and command the modem to answer after the
2nd ring (or if the /Rn command line switch is used, after the Nth
ring). This is why S0=1 and S0=0 are the only permissible values!
Refer to the main GT1400.DOC file for a complete discussion of the
available command line switches.
3. The "Modem Answer String". This string is located with the Host
Modem Init String under item #30 of the configuration screen. The
default value is:
ATA|
GT will issue this string to the modem whenever the ring count
reaches 2 (or the number indicated by the /Rn switch). This string
should not be changed, unless GT should not be allowed to answer
the modem. For example, one could erase this string and set S0=5,
so that the modem would answer on the 5th ring, but I don't advise
anyone do this.
4. The "Result Codes". Because the modem init strings above contain
V1, "verbose" result codes should be programmed. They can be found
under item #29 of the configuration screen. There are 16 possible
results. If the modem does not support all of these, simply leave
the extra strings in their default state. The program comes with
the default result codes set for use with a USRobotics Courier HST
modem. Please consult the manual for the modem in use and modify
this table to match. Remember, use the "verbose" (word codes), not
the "terse" codes. It IS POSSIBLE to use the "terse" codes, but
they are not as compatible with such services as PC Pursuit. It is
especially important that the result codes for the CONNECT results
are correct. GT uses these to determine the baud rate of the
incoming call. If they are wrong, then GT will not be able to talk
to the incoming caller, because the modem and GT will not be at the
same baud rate; they will be out-of-sync.
5. It is highly recommended that logging be TRUE during host mode.
Otherwise, all records of the host mode activities will be
discarded.
6. How to allow GT to hang-up during host mode. Since the "escape
code" must be disabled during host mode, otherwise some caller may
crash your system, the normal hang-up string, "~+++~ATH", will not
work! Therefore, GT cannot hang-up the modem, unless you set the
modem to normal DTR operation. During host mode, GT will drop the
DTR signal whenever he wants the modem to hang-up. Most modems
come from the factory set so that they ignore the DTR signal - you
must reset a switch or, in the case of the Hayes 2400 modem, you
must make an entry in the Modem init string to do this. In any
case, if the modem ignores DTR, it will not hang up during host
mode operations. Some modems which must be setup via the init
strings to handle DTR properly use either &D2 or &D3, please
consult the manual for the modem in use to determine the correct
setting.
7. How does GT determine when a connection is lost? The GT host
5
monitors the carrier detect signal from the modem, when this signal
goes low, then GT assumes that the connection has been lost. Most
modems come from the manufacturer with the carrier detect signal
forced high. "This is like having a telephone with no ringer."
Quote by Tom Jennings. Obviously, this must be changed. Some
modems have a switch that must be reset to enable a true carrier
detect, others require setup via the init string. Many of the
modems that require init string setup use &C1, please consult the
manual for the modem in use to determine the correct setting.
8. Another option available under the Alt-I, #30, the miscellaneous
options section, is the "Message base PATH". This option is to be
used to indicate to GT where the main or default message base is
located. This is the message base that the user will be initially
given access to upon calling the system. This should be an open
message base since all callers to the system that pass the logon
procedure will have access to this area.
9. Another option available under the Alt-I, #30, the miscellaneous
options section, it the "Default File Section". This option
indicates to GT where the main or default file section is located.
This is the file section that callers will see initially when they
access your system. This should be an area with the lowest
security access level, as everyone will be able to use it.
10. To designate the directory where the host mode receives files, you
should specify the DOWNLOAD directory path. This option is
specified under Alt-I, #30, the miscellaneous options section. The
user may be confused by the terminology here, so let me stress that
the DOWNLOAD directory is where GT POWER *receives* files, whether
in host or terminal modes. Further, the UPLOAD directory path only
pertains to Terminal Mode, as the host mode file areas are
otherwise controlled via entries in the GTDIR.BBS file, described
below.
11. To specify the directory where the host mode will save messages to
the sysop. These messages are entered with the 'M' command from
the main menu. This option is specified under Alt-I, #30, the
miscellaneous options section.
PLEASE NOTE:
The pathnames mentioned above are all found under the miscellaneous
options screen #30 of the Alt-I menu. Once the miscellaneous
options screen has been selected, then #13 on the miscellaneous
menu will bring up a window where all the pathnames may be altered.
6
Security Considerations
-----------------------
Many of GT POWER's design considerations were directed towards providing
absolute system integrity while in host mode. This section is designed
to highlight some of those considerations with the intention of making
the System operator of a host mode fully aware of both his protection
and his responsibilities in that regard.
The fundamental truth about security is that essentially it is YOUR
responsibility. GT POWER's first line of defense in your behalf is its
password function. Without a preassigned password, a remote caller
cannot gain access to the functions provided by GT POWER! Thus, it
stands to reason that your first responsibility is to assign those
passwords and TO GUARD THEM. Because there are several sets of
facilities that you will wish to control and to allow various users to
be provided selectively, GT provides several 'levels' of authorization
that may be assigned to each password. In this way, all users who log
on with the same password will have identical (and only those that are
assigned) access to GT facilities. For example, GT POWER provides to
users who have a sufficiently high 'level' of authorization, the ability
to shell into DOS and, thus, have the ability to execute ANY DOS COMMAND
from their remote location! Obviously, you would not casually
distribute that password amongst your user community. Most users should
NEVER be allowed to Shell to your DOS! (While in DOS a user could, for
example, format your hard disk - that would, of course, result in the
end of subsequent functionality of the entire system). To these users
you would assign a lower 'level' of authority. To do so you would
simply change their access level to the new level with the Sysop Tools
program.
One of the nicest features of the host mode provided by GT POWER are its
message data bases. With this feature the users of the system may leave
'mail' for other users and receive mail for themselves. Indeed, there
are two kinds of mail: Public and Private. Public mail may be read by
any user of the system. Private mail, on the other hand, may be read
only by the person sending it or by the recipient. Here, then, is
another area of security that you need to be aware of and control. For
example, say that you allow your system to be called by clients of your
firm and that they are encouraged to leave messages to you in your
absence. It is possible that several of your clients are competitors of
each other. Thus, it would be improper to allow them to read messages
sent by others. This is the reason for Private mail. At this point, I
would like to point out that there is no such thing as 'Private' from
the Sysop! That is, the System operator may read any message, whether
addressed to him or not and whether they are marked Private or not.
Finally, lest the earlier remarks did not sink in, any user who has
access to the DOS via the Shell command (because of his assigned
extremely high 'level' of authorization) can easily read any messages
while he is in the DOS Shell!
As far as sending PRIVATE messages to the System operator is concerned,
any user may do that! There is an 'M' command on the Main Menu that
results in messages that only the Sysop may view. These messages are
automatically addressed to the Sysop and marked as private. They are
placed in the message base specified for sysop messages, they may be
read only by someone with the Sysop authorization level. This message
7
base needs to be accessed at least once by the sysop during setup, to
insure that a message is entered to create all control files.
Otherwise, the system will not be able to process 'M' messages to the
sysop.
The hierarchy of access 'levels' based on password enables the Sysop to
control which directories on the disk those users have access to for
purposes of downloading files. However, each caller to the system will
be granted access to the "Default file section", which is a config
option. So please be sure that this file section contains the least
sensitive material on your system.
For ease of use, it is recommended that the user construct a batch file
to invoke GT POWER, especially host mode users. It should look like
this:
C: To specify a default drive of C
set GTPATH=C:\GT Remember to set GTPATH!
GT1400 !xxxx host.scr To invoke GT POWER
If the above batch file were called GT.BAT and placed in your system's
PATH then you could safely invoke GT by simply typing: GT. It is
important to note, that one of the most frequent errors reported to the
GT support staff is the incorrect setting of GTPATH.
As you will see when you read the next section (about the GTDIR.BBS
file), you can allow your users to have access to all directories that
have a matching authorization level OR LOWER. Further, you can specify
that particular directories are only available to specific authorization
levels.
Where is all this authorization level information kept within the GT
POWER system? In a file called GTPASSWD.BBS. That file, it is
unnecessary to say, is the key to the security of your system. One of
the subtle security features of GT POWER is that it will not allow that
file, even if it is contained in a directory that the user has been
authorized to Download from, to be transmitted over the telephone!
NOTE:
That the external protocols can transfer prohibited files and for
this reason, extreme care should be taken when using either DSZ.EXE
or PCKERMIT.EXE.
Similarly, because the Log file that is optionally maintained by GT
contains the user names and passwords of those who have logged onto the
system, it may not be transmitted over the telephone either.
When running in host mode the screen on the host system shows all
keystrokes entered by the remote user (except while he is in the DOS
Shell or using a DOOR, should that be allowed). In other words, if the
remote user, for example, entered a Private message to another user, or
to the Sysop, the text is showing on the host screen as it is typed. If
the user were to log off immediately after entering the message then it
would be possible that the text of the message remained on the screen.
GT POWER erases the screen after the caller hangs up to prevent such a
lapse in security.
8
If you are running a host mode system in an environment where others
might be able to observe the screen then it is recommended that you turn
your monitor off while you are not in attendance.
If others may be in the area as you are communicating (chatting) with
users and you wish to control the information on the screen you would do
well to remember that the Alt-W keystroke will erase your screen
instantly.
A user-name may be BANned from accessing the system. Note, however,
that doing so merely encourages an undesirable to log on with another
user name. With the advent of personalized passwords, this provision
has become more effective, since one could setup the system password to
have a low access level, which would be raised only after validation.
Computer time is a resource that you can also control in host mode.
Each password may have a designated time limit beyond which the caller
will be automatically logged off. The number of calls per day made to
your system by an individual caller is also subject to control.
One of the more subtle security measures built into the host mode of GT
POWER is called a 'Watchdog'. Should an authorized user be in the DOS
Shell or out a DOOR, and for any reason he were to drop his carrier
(hang-up), the system would then be vulnerable to the next caller as
that caller could find the system "in" DOS and he would then have
uncontrolled access to do as he pleased to your system. In the
situation mentioned, loss of carrier, GT will force your system to
reboot and if you setup the AUTOEXEC.BAT file properly, when the system
completes rebooting it will invoke GT and put it back in host mode! The
same thing would happen, for example, if power were to be lost during
host mode. When power is restored the system will automatically return
to the host mode of GT POWER. Note, however, that for those systems
that do not have a built in clock, the time and date of the system would
no longer be correct.
As a Sysop of a host mode GT system you must be aware that there are
some legal considerations that you may face. For example, should you
allow users to place copyrighted programs onto your system and to then
allow other users to download those same programs, then you are
participating in an illegal activity! Naturally there is no way to
prevent a user from sending you copyrighted material, provided he has
upload capability. There are many things that you can do, however, to
stop others from having access to that material. For example, GT POWER
allows you to cause all files that are uploaded to your system to be
placed into a special receiving directories, rather than into the
directory the user is currently using. It makes good sense to make a
receiving directory PRIVATE, in the sense that it is NOT listed as
available in the GTDIR.BBS to your remote users. In this way, you may
review the files received at your convenience and move them over to the
public directories if you are satisfied that they are either public
domain or Shareware programs and files.
Another reason that you will want to do the above is that there are a
few people out in the world that like to send what are called Trojan
Horses to BBS's. A Trojan Horse is a program that causes some form of
9
damage when it is run. It would not be at all fair to your users to
expose them to such programs. So, when it is safe for you to do so,
either run the programs you receive (using BOMBSQAD or a similar program
to prevent a problem for you). When you are satisfied that the programs
received are safe then you can move them to public areas.
And in the event that a user does send you a Trojan Horse or copyrighted
code, it is in your best interest to know who did so. GT POWER provides
an optional log file function. If that is enabled, which is highly
recommended, then the log contains the name of the person who logged on
and sent you the file.
This section of the document is substantially larger than you may have
expected it to be. The reason should now be obvious.
We remind you again, YOU are the person responsible for security. It is
necessary that you know the previous information and take appropriate
actions.
10
Host Mode Text Files
--------------------
The following text files must be created and/or maintained with an
editor that can produce plain ASCII files. Any of the display type .BBS
files may have a DC2, Ctrl-R, character inserted into column 1 of line 1
to disable the "More?" prompt during display of the file, and a DC4,
Ctrl-T, character inserted into column 1 of line 1 to disable the Ctrl-K
and/or Ctrl-C user break, or a ENQ, Ctrl-E, character inserted into
column 1 of any line to force a "More?" pause at that line.
+---------------------------------------------------------------------+
| |
| Ctrl-E ... ENQ ... Insert a "More?" at current location. |
| Ctrl-R ... DC2 ... Disable "More?" during file display. |
| Ctrl-T ... DC4 ... Disable ^K/^C break during file display. |
| |
+---------------------------------------------------------------------+
Using the Ctrl-R to disable the "More?" prompt is useful when the file
contains such graphic or annimation techniques that would be spoiled by
such interruption. Except for the GT?DIR.BBS files, every .BBS file can
have two versions: (a) a color graphics version or (b) a plain text
version. This is coordinated with the ANSI graphics question asked of
callers before they logon the system. The .BBS extension is the default
used if only one version of the file can be found by GT, the .CBS
extension is used to indicate to GT that a graphics version is
available. If both versions are available, the .CBS version will be
shown to callers who elect graphics, if graphics are not elected by the
caller, the .BBS version will be displayed.
GTSYSID.BBS This file is displayed as soon as the GT host detects a
connection has been established with an incoming call.
After displaying this file, GT will ask the user if the
terminal program he is using supports ANSI graphics.
GTWELCOM.BBS This file is displayed to a caller just before he is
asked for his name by the GT host. It should identify
the system to callers.
GTPASSWD.BBS This file contains the list of passwords that people
must know to access the system. The entries in this
file are composed of one line per password, and each
line contains the following information, beginning in
column 1:
Lvl ([xx:xx(,n,hh:mm,path)]) Pwd Auth (1st-Name Last-Name Phone-Number)
These items can have a variable number of blanks between
them, but the "Lvl" must begin in column 1. EACH
PASSWORD, "Pwd", MUST BE UNIQUE and from 1-20 characters
in length.
The () which have been shown around the call time limit,
the daily call limit, the daily time limit, the name,
and phone number fields, indicate that these items are
11
optional and need not be included in the file.
Field descriptions:
-------------------
Lvl .... The Access Level assigned to this entry. May
be any character from the following sets: 0-9,
A-Z, or a-z. NOTE: "0" is the highest level
and "z" is the lowest.
xx:xx .. The Call Time Limit. This field is optional
and is enclosed within [...]. If omitted, it
defaults to approximately 24 hours.
n ...... The Daily Call Limit. This field is a sub-
field within the [...] of the Call Time Limit
field. It cannot be specified without the Call
Time Limit being specified also. Example:
[1:30,2] would grant two calls per day of 1:30
duration each.
hh:mm .. The Daily Time Limit. This field is a sub-
field within the [...] of the Call Time Limit
field. It cannot be specified without the Call
Time Limit and the Daily Call Limit being
specified also. Example: [1:00,5,2:00] would
grant five calls per day, each of up to 1 hour
each, but a maximum of 2 hours per day total
usage.
path ... The upload pathname. This specifies where
files uploaded by a particular class of user
are to be stored.
pwd .... The Password. As said above, the password may
be from 1-20 characters in length and must be
unique. If this line is a class entry the
"pwd" field should contain the word CLASS in
capital letters.
auth ... The Authorizations given to this entry. They
come from the following list:
UP : Upload authorized.
DN : Download authorized.
PR : Private mail authorized.
SY : Sysop priveledges authorized.
CH : Manual directory change is
authorized (in absence of the
GTDIR.BBS file).
SH : Shell to DOS is authorized.
DR : Use of DOORS is authorized.
MS : Allows message reading.
FR : Allows file request/attach when using
the netmail programs.
NL : Disable the L)ist directory command
at the main menu.
12
NE : Disable the E)nter message command.
These authorizations are listed seperated by
commas, following the "pwd" field. See
examples below. The CH authorization is a "do
nothing" authorization in most cases, because
most systems use a GTDIR.BBS file. On these
systems the CH option may be used as a way to
grant no authorization, because a total lack of
authorization yields the default authorization
set: DN,UP,PR,MS.
1st-Name Last-Name Phone-Number
These three fields are present when it is
desired to allow the caller "callback"
priveledges. In effect, if the caller's name
matches the name listed here and he gives the
correct password, the system will offer to call
him at the listed number. This allows the host
to assume the cost of the phone charges for the
session. The caller must be prepared to accept
the call, that is his modem must be in "auto-
answer" mode. Send "ATS0=1|" to most Hayes
type modems to set auto-answer mode. The "|"
represents a "carriage return". If the
conditions are met GT will return the call
within 15 seconds, and will retry 3 times
before giving-up hope of establishing the
connection. NOTE: the password assigned here
for the callback, must *not* be the same as the
caller's personal password -- the callback
password *MUST* be unique.
NOTE:
It is possible to append a single character to the level
indicator. Thus "A1" would be a valid level. This
extra character is used to identify a custom bulletin
file for this caller. This extra character is optional,
but if present MUST BE a character that is legal within
a file name. Read about BULLET files below.
Examples:
A [2:00,100,5:00,c:\goodies] MASTER SY
B1 [1:00] FRIEND DN,PR
B1 [1:00,4,2:00,c:\up] CLASS DN,UP,PR
C [1:30] JOGGER DN,UP,PR,DR MARY ADAMS 1-213-555-1234
A [2:00,10,4:00] CLASS SY
C2 [2:00,3,3:00] CLASS DN,UP,PR,DR
In version 12.10 of GT POWER, personalized passwords
were introduced. When a caller gets his personal
password it is stored in the GTMAIL.CTL file, with the
other user information. The access level assigned to
the password used by the caller on the first call
(before a personal password was assigned) will be the
access level assigned to the caller until changed via
13
the Sysop Tools program. To provide a time limit, daily
call limit, and bullet #, a cross reference of the
access level stored in the users record in GTMAIL.CTL
file and the GTPASSWD.BBS file is required. This is
accomplished by placing CLASS cards for each access
level your system uses into the GTPASSWD.BBS file. The
format of the CLASS card is the same as a normal
password entry, except the word CLASS must appear in
uppercase letters. In addition, the CLASS entries
cannot be used to provide callbacks, normal password
entries must be provided for that purpose. Here are
some example CLASS entries:
Examples:
A1 [2:00,5,3:00] CLASS DN,UP,PR,DR,SH,MS
B3 [1:30,2,2:00] CLASS DN,PR,MS
K2 [:45,1,:45] CLASS DN,UP,PR,DR,MS
The first CLASS entry establishes a class for callers
with an 'A' access level, grants them 2 hours of session
time, and a daily call limit of 5 calls, 3 hours of time
per day, and gives them the authorizations: Download,
Upload, Private mail, use DOORS, Shell to DOS, and read
messages. The other entries grant lesser time amounts
to the 'B' and 'K' classes. The 'B' class is given
Download, Private mail, and read messages
authorizations. The 'K' class is given Download,
Upload, Private mail, use DOORS, and read messages
authorizations. Note: if you neglect to setup CLASS
entries then once your callers have been assigned their
own personal passwords, this is automatically done by
GT, then they will have unlimited time access to your
system, the default authorizations, and they will not be
given a bullet #.
+-----------------------------------------------------------+
| |
| Remember to give callers the MS authorization |
| so they can "read messages". And setup a CLASS |
| entry for each different access level in use. |
| |
+-----------------------------------------------------------+
GTBULLET.BBS This file is displayed for the caller after he/she
completes logon. It is useful to leave notes here for
expected callers.
BULLETx.BBS The "x" may be any character that can be a legal part of
a filename. This character must match the character
which is found after the level indicator in the password
file, to enable custom bulletin files to be displayed
for callers. For example: if a caller's level was "BZ",
then the program would search for a file named
BULLETZ.BBS to display whenever the caller logged onto
the program.
14
NOTE:
Custom bulletin files are OPTIONAL. If you do not wish
to use them, simply use single letters for access level
indicators.
GTMENU.BBS This file is displayed for callers as the main menu. It
may be suppressed by a caller by selecting X)pert mode.
GTHELP.BBS This file is displayed for the caller if he/she requests
help with the main menu.
GTBYE.BBS This file is displayed for the caller when he/she logs
off, i.e. selects the G)oodbye command from the main
menu.
GTBYEx.BBS This is a custom bye file. The 'x' may be any character
that can be a legal part of a filename. It comes from
the GTPASSWD.BBS file, as the letter following the level
indicator. Most commonly a number. See custom
BULLETx.BBS files above.
GTUSER.BBS This file is created whenever a call comes into the
system. It will contain the access level and name of
the current caller, or if no call is in progress, the
previous caller to the system. The file contains just
this 1 line of text. The exact format is:
Lvl 1st-Name Last-Name auth baud-rate ANSI-opt last-on limit event time
The line is free format with spaces delimiting fields.
The "auth" field will contain the authorizations given
this caller from the GTPASSWD.BBS file when he logged
onto the system. The "baud-rate" field will be one of
the following numbers: 300, 1200, 2400, 9600 or the word
LOCAL, if the sysop is logged-on. The "ANSI-opt" field
will contain "NOANSI" if the caller doesn't want ANSI
graphics, or "ANSI" if he does want the graphics. The
"last-on" field contains the date the user last called
the system. The "limit" field contains the remaining
time the caller has left for the current call. The
"event" field contains the time remaining until the next
event is scheduled. The "time" field contains the
current time in "xx:xx" format. The time remaining
fields are integer showing time left in minutes.
The purpose of this information is to supply needed
control information to external programs that run either
in the Shell to DOS or DOOR environment.
GTDIR.BBS This file contains a list of directories that may be
accessed by callers. There are two types of lines in
this file: the actual directory lines and comment lines.
The comment lines are displayed to the caller when he
asks to see the list of directories. The list displayed
will contain only those directories the caller is
authorized to access. The formats:
15
Comment Lines:
Contain a blank in the 1st column, the remainder of the
line is displayed for the caller.
Directory Lines:
Column 1 - access Level. The minimum level required to
access the directory. If this column contains an "="
then the actual line is shifted to the right 1 column
and the "=" acts to reserve the directory for the
indicated access level - which would now be in column
2. (See example.)
One or more blank columns follows the level, then the
complete DOS name of the directory, including all drive
and PATH information. One or more blank columns follows
the directory name, then a description of the directory
is given. When a caller selects the C)hange directory
command, the list of choices will display the
descriptions you provide here, so try to be helpful.
Examples:
This is a comment. (Since column 1 is blank)
A C:\DOS\TEST The description goes here.
=B C:\LOTUS\DATA This is for "B" level callers only.
C A:\ The description again goes here.
This example shows three directories, one with an "A"
access level, one with a "C" access level. These are
the minimum levels that callers must have to "see"
these directories. The "=B" directory may only be
accessed by a caller with the "B" access level.
NOTE:
When host mode is started, the then default directory
will be made available to all callers, regardless of the
contents of GTDIR.BBS. So it is advised that this
directory require the least security and that it be the
1st entry in the GTDIR.BBS file.
GTDDIR.BBS This file controls access to the GT DOOR system. Its
function is much like GTDIR.BBS is for file directories.
It serves as a way to add security to doors, document
them and pass parameters to them. Each door must have
an entry in this file, there are no comment lines in
this file. Each line in this file follows the this
syntax:
Lvl ([comment_here_with_no_spaces]) (Prompt message here:)
The () indicate which fields are optional and need not
be included in the file.
As with the GTDIR.BBS file, the "Lvl" controls the
minimum access level required to open the door. The
16
[comment] is optional, but must be enclosed within [...]
if it appears and no blanks are allowed within the
comment field. If a parameter must be passed to the
DOOR, then the optional prompt field must be added. The
answer given to this prompt by the caller will be passed
to the DOOR as command line argument %3.
Examples:
B [this-is-door-1]
Z [this-is-door-2] Enter filename:
S [this-is-door-3]
In the example above, the 2nd door has a prompt listed
that indicates that this door requires a filename be
passed. This could be for example to implement an ARC
view type door, where the name of the ARC to be
processed might need to be supplied. The caller's
response will be passed as command line argument %3 to
the GTDOOR2.BAT file in this case.
+------------------------------------------------------------+
| |
| Please note, the order of the lines in this file |
| must be 1st door on 1st line, 2nd door on 2nd line, |
| etc. The lines must be in 1, 2, 3... order. |
| |
+------------------------------------------------------------+
GTBMENU.BBS This file is the bulletin menu file. It should list the
numbered bulletin files. The numbered bulletin files
should be located in the "Default file section", and
their file names should simply be 1, 2, etc. This menu
file will be displayed as users logon your system and
besides the numeric bulletins, two alpha options should
be listed: L)ist logon bullets and Q)uit bulletin menu.
An example of a GTBMENU.BBS file:
1. Bullet #1 description here.
2. Bullet #2 description here.
.
. etc.
.
L)ist logon bullets
Q)uit bulletin menu.
GTMDIR.BBS This file controls the multiple message bases that GT
can support. The format of this file is the same as the
format for the GTDIR.BBS file, except that you have 1
additional option for column 1, you may place a '*' in
column 1 of an line in this file and then that message
area will become a 'by application only' message base.
The caller applies for entrance by trying to select the
message area via the A)rea change command. GT will
inform the caller that application has been accepted and
the Sysop must approve. The users name will be placed
into the GTMAIL.CTL file associated with the message
17
base, but the BAN bit will be set, the Sysop must use
Sysop Tools to reset the BAN bit so that the caller can
be admitted.
When setting up, the Sysop should insure that all
sub-directories listed in GTMDIR.BBS exist, but GT will
automatically provide all the control files and message
directories, as needed.
All message areas must have an entry in this file. The
main default message area must be open to all callers
and must use the same pathname as the message base
pathname in GT's configuration file. The GTMDIR.BBS
file must be located with the other .BBS files in GT's
home directory.
+--------------------------------------------------------------+
| |
| The PATH name portion of the lines in the GTMDIR.BBS |
| file may be prefixed with either a ^ and/or a ~ . |
| |
| The ^ designates a message area that can support |
| public messages only. The ~ designates a message |
| area that is used as a netmail area(see netmail docs). |
| |
+--------------------------------------------------------------+
Examples:
Z ^C:\GTBBS\OPEN Public Message Base
E C:\GTBBS\GENERAL General Message Base
F C:\GTBBS\SPECIAL Special Message Base
Z ~C:\GTBBS\PUBLIC Public Netmail Area
GTDOORS.BBS This file is displayed for the caller when he selects
the O)pen DOORS option from the main menu. It is a pure
text file, which should contain your DOOR menu. Each
DOOR is assigned a number, 1-99, and should be listed on
this menu by the number needed to select the door.
GTDOORn.BAT These are the DOOR files themselves. These are batch
files, much like the Shell to DOS batch file, but
instead of executing another copy of COMMAND.COM, it
executes your DOOR program. The mechanism of the DOOR
is actually the CTTY commands at the start and end of
the file. The CTTY redirects the console to the COM
port at the start of the DOOR file, and back to the
console at the end. Sample DOOR files are included with
the package. Here is a short example:
%1 COM%2
EDLIN %3
%1 CON
The %1 will become "CTTY" or "REM", and the %2 will
become the port number, thru substitution by DOS. The
18
"REM" substitution is used when the DOOR is being run
locally by the Sysop to check it out. A DOOR that works
in the local mode may not work for a remote caller,
because the DOOR program may not use the DOS functions
to perform I/O with the console.
Remember that the 3rd command line argument is passed
from the GT host to the DOOR containing the response
from the caller to a prompt you have placed into the
GTDDIR.BBS file. In this case, it would have asked the
caller which file he wanted to edit.
ANSWERn.BBS This file contains the answers supplied by the callers
to the 'n' questionaire, that you have stored in the
QUESTn.BBS file. The format of this file is as follows:
each answer given by a user is written on a separate
line to this file, the answers are grouped by placing
the users name, from logon, onto the first line of the
group, enclosed within << ... >>, following this each
answer appears on a separate line and each group is
terminated with a line containing a single period. Here
is an example:
<< Paul Meiners >>
9350 Country Creek #30
Houston, TX 77036
713-772-2090
.
<< Susie Meiners >>
1245 Sunnyside Dr.
Houston, TX 77081
713-894-3465
.
The example shown above contains two groups of answers.
As GT accumulates answers it will continue to append
them to the end of this file. If this file does not
exist, GT will create it. The Sysop should avoid
editing this file, because any attempt to do so may
render GT incapable of adding answers to it.
QUESTn.BBS This file contains the questionaire for callers to fill
out. This feature is optional. The file is in template
format, using the [------] construct to indicate where
GT should gather answers to questions. For example:
[------------]
Enter Phone Number:
Would direct GT to collect the phone number, showing GT
where to collect the answer and the maximum width answer
to accept. Each answer can be up to 80 characters long
and there may be up to 50 questions per questionaire.
After having filled out the questionaire, the caller
will be asked if he wishes his answers to be recorded.
19
If he indicates in the negative, GT will discard the
answers.
The questionaire is optional, and if the user tries to
fill out a questionaire that cannot be found, GT will
indicate to the caller that there is no questionaire
currently available.
Date/time stamping can be done automatically by
including a special code in the questionnaire file. For
example:
[%DT]
Would cause the current date and time to be recorded in
the answer file (no question would be asked here), of
course the balance of the questionnaire would be
processed in a normal manner.
There can be up to 99 different questionnaires for the
caller to choose from. The GTQMENU.BBS file is
displayed with a list of all available questionnaires.
PQUESTn.BBS This file is displayed for the caller immediately after
he selects the questionaire he/she wishes to complete
from the questionnaire menu. It should explain to the
caller the basic purpose of the questionaire and allow
him to consider if he wishes to continue to fill out the
questionaire. Immediately after this file is displayed,
the caller will receive a prompt, asking if he wishes to
continue and fill out the questionaire.
The PQUESTn.BBS file is optional.
GTQMENU.BBS This file is listed for the caller when he selects the Q
option from the main menu. It is a menu file that
should contain a list (in text format) for the user to
choose which questionnaire he wishes to complete. For
example:
1. Order form for GT POWER.
2. Order form for Turbo CALC.
3. User poll.
This shows only three options, as many as 99
questionnaires may be supported by the system.
PROTOCOL.BBS This file contains the protocol menu that will be
displayed for the caller if he initiates a file
transfer. It is provided so that the Sysop can
customize this menu to his own taste. It is pure text
format, except for the first line, which contains the
list of protocols the Sysop wishes to activate for his
system. The format of this activation line is as
follows:
20
;XYZB1TWKMSG
Where the ";" appears in column 1 of the line. Each
letter activates a specific protocol, as follows:
X ... Xmodem
Y ... Ymodem
Z ... Zmodem
B ... Ymodem Batch
1 ... 1k Telink
T ... Telink
W ... WXmodem
K ... Kermit
M ... MegaLink
S ... SEAlink
G ... Ymodem-G
By omitting the activation letter from this line, the
Sysop may disable the corresponding protocol. For
example:
;XYZT
Would activate and allow on the Xmodem, Ymodem, Zmodem
and Telink protocols. The other protocols would not be
allowed.
The PROTOCOL.BBS file is optional, if omitted GT will
display a canned protocol menu.
WELCOME.BBS Each message base may have a welcome screen. It
present, it resides in the directory with the message
.CTL files and is displayed for the caller as he enters
the message base. It is in the nature of a conference
welcome screen. The WELCOME.BBS file is optional.
MBULLETx.BBS Each message base may have bulletins associated with it.
These bulletin files will reside in the directory with
the message .CTL files and will be displayed for the
caller after the WELCOME.BBS file has been displayed.
The bulletin numbers are coordinated with the regular
bulletin numbers in the main GT directory, which come
from the bulletin numbers on the entries in the
GTPASSWD.BBS file.
The MBULLETn.BBS files are optional.
SYSOP.BBS This file contains the custom welcome to Chat Mode - the
mode that is entered when the Sysop answers a Page.
Normally this file contains something like ", here is
the SYSOP." It may be changed to reflect the name of
the Sysop, or whatever. Using the normal contents, the
caller would see:
Caller Name, here is the SYSOP.
21
Of course, the actual caller's name will replace "Caller
Name".
SCHEDULE.BBS The "scheduler" is code within the GT host mode which
allows the sysop to schedule events. The format of the
SCHEDULE.BBS file is very simple. The file is composed
of lines that begin with a time or range of times, then
the command to be executed at the specified time.
Examples:
03:00 copy file1 file2
03:30 QUIT 5
04:00-05:00 QUIT 6
06:00 maint
Based on the above example, at 3 a.m. the GT host will
copy file1 to file2 (any DOS command can be executed
like this). Then at 3:30 a.m. the GT host will quit
execution and set an ERRORLEVEL of 5, the runstream that
is controlling GT must be prepared to deal with this
ERRORLEVEL, else nothing will be done. Also the user
must insure that the GT host is restarted. At any time
between 4 a.m. and 5 a.m. the GT host will quit
execution and an ERRORLEVEL of 6 -- this one is meant to
illustrate a quit to the netmail function, which should
always be started with a range of times, so that in case
it cannot start exactly on the button of 4 a.m. the GT
host will start it, even if it is late starting. Again
the runstream that is controlling GT must be prepared to
deal with the indicated ERRORLEVEL, 6 in this case, and
must restart the GT host after 5 a.m. Then at 6 a.m.
the GT host will execute the 'maint' batch file. NOTE:
when the GT host starts a command like this, it is done
via the SHELL mechanism, this requires alot of memory
and it is not recommended if you are using multi-
tasking software. The netmail documentation includes
examples of how this can be setup.
A sysop may also add a special line to the SCHEDULE.BBS
file which will allow control of the P)age function from
the main menu. The OFFICE command allows the sysop to
specify when a P)age will be acceptable. If a P)age is
attempted outside of the specified time range, then the
caller will be notified about the sysop's OFFICE HOURS.
Here is the format: OFFICE=08:00-21:00
The hours must be given in 24:00 notation, and please
notice that leading zeros, must be supplied. 08:00 is
correct, 8:00 is wrong! No embedded spaces are allowed
in this format. It must be as shown above.
+-----------------------------------------------------------+
| |
| NOTE |
22
| |
| Five minutes prior to a external event, GT POWER |
| will cease accepting calls and wait for the event |
| start time. Callers who call in the vicinity of |
| an event will have their time on the system cutback |
| so that the caller will be off the system before |
| the event is to start. |
| |
| |
+-----------------------------------------------------------+
FILES.BBS When you create a directory to contain files, either for
upload or download, you should include within the
directory a file named FILES.BBS. It should contain the
descriptions of the files contained within the
directory. When the caller selects the "F" option from
the main menu, the content of this file will be
displayed.
The FILES.BBS that is located in the appropriate upload
directory will be updated automatically with information
supplied by the uploader as follows:
Position Description
-------- -----------
1-12 Filename
13 Blank
14-16 File size in kilobytes
17 Blank
18-25 Upload date
26 Blank
27-79 File description
23
Host Mode Control Files and Directories
---------------------------------------
During the operation of the GT host mode, two files and one directory
will be created automatically, for each message base. The Sysop Tools
program must be used to maintain these files, when the need arises.
Here is an overview of the purpose of these files:
GTMESSAG.CTL This file contains the header information for all
messages maintained by the GT host. Such information as
sender name, addressee name, date of entry and whether
or not the message has been received, are kept here.
GTMAIL.CTL This file contains information about the callers to your
GT host. Such as their name, where they are calling
from, the last message they have read, etc. Also
contained in this file are the personal passwords and
access levels of each caller.
GTMSGS This is a sub-directory where the text of the messages
is stored. Each message is stored in a separate file
without the header information, which is stored in the
GTMESSAG.CTL file. The messages are named with the
message number as the main filename and extension of
.MSG.
These files will be created as necessary by the GT host, they will be
created in the directory pointed to by the "Message Base PATH" in the GT
configuration, or if that is not used in the home directory and drive
from the environment variable GTPATH, or if that variable is not used,
in the default directory at program start-up. The program Sysop Tools
will perform needed maintenance of these files: for example renumbering
the messages, deleting obsolete users, providing reports and listings.
HOWEVER, do not run Sysop Tools prior to establishing these files.
24
Running Host Mode
-----------------
Once installed, host mode is fairly self-explanatory, but here is a
quick once over.
Host mode is started by pressing "ALT -". GT will automatically enter
"Half duplex" mode. This is so that anything typed on the host console
will echo so that it can be seen. Then GT will send the host mode
Modem Init String to the modem and wait for a call. While GT is
waiting for a call, there are 4 commands available: [Esc], which will
terminate host mode, carriage return, which allows the Sysop to logon to
GT's host mode from the local console, [Ctrl-L], which turns on the
system printer for logging, and [Ctrl-S] to load a fresh copy of the
schedule from disk. Note that you must have logging enabled in the GT
configuration, via Alt-I, the [Ctrl-L] command merely enables the
printer, so that whatever is logged will also appear on the system
printer. There also is a command line option to turn on the log
printer. If you place "/p" on the GT command line, the printing of the
log will automatically be turned on from the very start of the program.
Once GT has answered an incoming call, there are several commands
available to the operator, as follows:
+---------------------------------------------------------------------+
| |
| SYSOP COMMANDS |
| |
| Alt-H List available sysop commands. |
| |
| Ctrl-D List current schedule on the screen. |
| Ctrl-L Toggle log printer on/off. |
| Ctrl-N Raise caller's access level while on-line. |
| Ctrl-P Sysop initiated chat mode. |
| Ctrl-R Reset time limit, gives caller more time. |
| Ctrl-S Load new schedule from disk. |
| Ctrl-T Terminate after current caller disconnects. |
| Ctrl-X Abort the caller. |
| Ctrl-Z Terminate chat mode. |
| |
+---------------------------------------------------------------------+
Command Line Usage
------------------
When you start GT, there are several command line switches that are
available to you:
name You may indicate a script file to be executed upon start-up of
GT.
/D You may indicate whether or not you wish to have GT drop the
DTR signal to the modem when GT exits back to DOS.
/C You may indicate whether you are connected via cable to the
host computer.
25
/K You may initiate the capture mode from the very start of the
program.
/P You may enable logging to the system printer.
/1 You may configure the port addresses in use by your serial
port. The actual port number to be configured, 1-4, is placed
after the slash. The new base address of the indicated port
is placed after the slash number with an intervening blank.
The address must be given with a leading $ sign and be in hex
notation, for example $3F1 would be a valid address. Refer to
your hardware documentation for the correct address to use.
GT uses standard addresses if you do not override with this
option.
/Rn This option applies to the GT host mode. It specifies the
ring number upon which GT will answer incoming calls. For
example /R3 would cause GT to answer on the 3rd ring. NOTE:
that the host mode modem init string must contain S0=0 to
allow this to work properly.
/RBmm:nn This option applies to the GT host mode. It specifies that GT
should answer the modem after a "ring back". To enable this
to work properly, the host mode modem init string must contain
S0=0. Once installed properly this option makes the GT host
mode answer the phone on the 2nd or 3rd ring after a gap of
between 'mm' and 'nn' seconds. If the gap between rings is
less than 'mm' seconds or greater than 'nn' seconds, GT will
not answer the phone. This allows the use of an answering
machine on the same phone line as the computer. The answering
machine should be programmed to answer on a later ring, the
4th for example. The 'mm:nn' is optional, and will default to
a 9 to 32 second gap.
+----------------------------------------------------------------------+
| |
| This listing of command line switches came from the main GT |
| documentation file. Please refer to that document for sample |
| usage of these switches. |
| |
+----------------------------------------------------------------------+
26
Host Mode LOG
-------------
A few sections above, I suggested that logging be TRUE, while GT is
running in Host Mode. Here is why: during Host Mode operations, GT will
log all of the calls received, who called and the password used. A
record will also be kept of who tranfered each file, how long it took
and the efficiency of the transfer. I consider the gathering of this
information to be critical to the operation of a GT Host.
The Shell to DOS
----------------
The DOS Shell allows remote callers to operate your computer remotely.
When the "Shell to DOS" option of the main menu is selected, GT will
shell to the file GTDOOR.BAT. This file will set up for the remote
shell by executing the proper CTTY command, then execute a secondary DOS
shell and let the user into the system. He will have the console, so be
cautious! The caller will be instructed to issue the "EXIT" command to
return to GT.
While the DOS Shell is active and the caller is out in the system, GT
will not be idle. GT will act as a watchdog. If the caller should hang
up while the DOS shell is active, GT will force the system to re-boot
and will drop the DTR signal to the modem. If commands to start GT are
placed in the AUTOEXEC.BAT file and a script is used to start Host Mode,
then GT will automatically recycle. The script command to start Host
Mode is simply HOST.
NOTE:
For this process to work correctly, the COMMAND.COM file must
reside in a directory pointed to by the PATH environment variable.
In order for this to work on a normal drive C: hard disk, "C:\"
should be added to the PATH variable. For example:
PATH=c:\dos;c:\lotus;c:\
This will ensure that the COMMAND.COM file can be located for
execution by the GTDOOR.BAT runstream.
A problem with the DOS Shell has been reported when using DOS 2.xx.
This is caused by the fact that DOS 2.xx does not support full
pathnames when requesting the execution of a program. To work
around this problem, if you have DOS 2.xx, you should place the
GTDOOR.BAT file in some other directory besides the GT home
directory. If GT finds GTDOOR.BAT in his home directory, then GT
will issue an EXEC function with full pathname, otherwise GT will
not specify any pathname and will rely on the DOS PATH command.
The directory where GTDOOR.BAT is stored must be pointed to by the
DOS PATH command in this case.
27
Using the Shell to DOS
----------------------
What can one do, once one is running DOS remote via a CTTY command?
Well, one can't use any of the Fn keys or the other special keys on the
IBM key-board! One can't run any program that does direct hardware
control of the screen or keyboard. All screen and keyboard input must
be done through DOS. Well, then what can one do? One can run any DOS
command; for example COPY, ERASE, DIR and others, including EDLIN, all
work properly. In fact, any program that uses the standard DOS handles
for input and output to the console will work. But one still won't have
F1 - F10 or the other special keys. Well, that's not quite so...if the
Host Mode computer is setup so that the ANSI.SYS device driver is loaded
via the CONFIG.SYS file. Just put a line like this one into the
CONFIG.SYS file:
DEVICE=ANSI.SYS
Naturally, ANSI.SYS must be located in the root directory of the boot
disk. After that has been done, re-boot the computer. ANSI.SYS will
then be loaded. One can now re-map the keyboard so that the special
keys are mapped to Ctrl keys instead. This will enable programs to be
run that use these keys; for example EDLIN uses the arrow keys as well
as several function keys.
How does one re-map keys with ANSI.SYS? The following sequence must be
issued for each key that needs to be re-mapped:
ESC [ ##;##;##;...p
The (...) indicate that the sequence may be repeated as needed, but each
sequence only re-maps one key. Once a file containing these mapping
commands has been created, they can be sent to ANSI.SYS by TYPEing the
file. The "##" in the sequence above indicate the ASCII codes for the
keys to be mapped. For example, let's map F3 to the Ctrl-D key. The
ASCII codes for F3 are 0,61 and the ASCII code for Ctrl-D is 4. (Note:
the special keys have two codes - the first is always 0. These codes
are really called extended ASCII codes.) Therefore, the proper ANSI.SYS
command to re-map F3 to Ctrl-D would be:
ESC [ 4;0;61p
Note:
Blanks are included for readability only, the "p" must be
lowercase, and the symbol ESC stands for the escape character,
CHR$(27).
28
Generic Tool Interface
----------------------
The GT Host Mode now supports a Generic Tool Interface. The purpose of
which is to allow utility writers to more intimately interface their
programs to GT. In this process, GT gives up all of its memory to the
tool program, thus allowing much greater access to memory for the tool
program. The GTI will be based upon the DOS EXEC function as
implemented in the C library function "exec...". This means that GT
will be completely overlaid by the tool program and to return to GT, the
tool program must invoke GT in the same manner it was invoked. Here is
the complete interface description, the nomenclature is that of the C
manual, since this is expected to be of use to C programmers only.
arg0 .... Name of child program (full pathname).
arg1 .... "-exr", indicates remote operations.
"-exl", indicates local operations.
arg2 .... Name of parent program (full pathname, needed for
return).
arg3 .... COM port number.
arg4 .... Baud rate.
arg5 .... Parity.
arg6 .... Databits.
arg7 .... Stopbits.
arg8 .... Flags (for use by GT only).
arg9 .... Registration key ("-nokey" is unregistered).
Much of this information is included simply to restart GT once the tool
program is finished with its work. When the tool program is prepared to
return to GT, it should swap 'arg0' and 'arg2' and reinvoke GT via the
"exec..." function.
If you write a program that uses this interface you will need to inform
your users that they can invoke the interface thru a macro key. The
{@/} is the macro command that invokes the GTI in GT. The actual coding
of the macro key would look like this:
{@/}c:\gt\gtexec.exe|
Which would invoke a program called GTEXEC.EXE in the C:\GT directory.
Naturally, this program had better be prepared for this invokation or it
will not return to GT when finished!
Remote Sysop Interface
----------------------
This interface is totally user configurable. At the main menu of the GT
Host mode, the sysop can enter one of the numbers 1,2,3,4,5,6,7,8,9,0.
These numbers correspond to the macro keys Alt-F1 through Alt-F10. For
example, if the sysop enters a 1 then the command in Alt-F1 is executed.
If he enters a 0 then the command in Alt-F10 is executed. If a non-
sysop tries to enter any of these numbers the program will treat them as
invalid input. This feature could have many uses, but is intended
primarily as a way to remotely execute the GTI (described above).
29
Usage of Color
--------------
The GT Host mode now includes color built-in to the various prompts and
menus. These colors can be configured. The colors used are of two
different sets. The first set is composed of the colors for the "Window
foreground and background", and the "Phone directory high lite
foreground and background". These colors should be subdued, since they
are used for normal informational type displays. For important command
line and menu displays, the program will use the colors designated for
"Option high lite" and "Option low lite".
The user can customize the sysop prompt with these colors, by including
the color codes in the SYSOP.BBS file. Here is the code scheme:
% ...... Used to kill the meaning of the next character.
%% ...... Used to display the % character.
$ ...... Shift the pallette to the "Window foreground/background"
set.
& ...... Shift the pallette to the "Option high/low lite" set (the
default).
[] ...... High lites whatever is between the [ and ].
~ ...... Kills the color. Goes back to standard B&W image.
For example:
$ [SYSOP] John~ here.
This would shift pallette to the "Window foreground/background" set,
high lite the word "SYSOP" and kill the color after the name "John".
Actually, this scheme was only intended to add color to the SYSOP.BBS
file and other built-in menus and prompts, but some have already
discovered that these colors can be added to the GTMDIR.BBS and
GTDIR.BBS files, to add color and emphasis.
Logon DOOR
----------
In the GT POWER home directory, it is possible to create a DOOR file,
with a special name, that will be executed whenever a user logs onto
your system. The file is named 'GTLOGON.BAT' and it is constructed in
the same manner as a normal DOOR batch file (shown above). For example:
%1 com%2
...the DOOR stuff here, varies with each application...
%1 con
The sequence of events goes like this after a user calls your system:
1. The GTWELCOM.BBS is displayed.
2. Then any BULLETx.BBS is displayed.
3. Then the GTBMENU.BBS is displayed.
4. Then the GTLOGON.BAT is executed, if available.
30
Logoff Batch File
-----------------
It is possible to have a logoff batch file. This is not a DOOR, but
simply a batch file that GT POWER will run, if it is available, whenever
a user has disconnected from your system. It may contain any normal DOS
command or other processing as required, if enough memory is available.
GT remains in memory while this batch file executes in a normal DOS
Shell. It can be useful for sysops that want to backup their files if
they are using a RAM disk for things like the log file.
Please note, this is not a DOOR, that CTTY is not redirected, and that
the 'watchdog' is not enabled during the execution of this batch file.
31
APPENDIX
--------
Here is a handy list of extended ASCII codes:
Key Codes Key Codes
--- ----- --- -----
F1 0,59 Right Arrow 0,77
F2 0,60 Left Arrow 0,75
F3 0,61 Up Arrow 0,72
F4 0,62 Down Arrow 0,80
F5 0,63 Home 0,71
F6 0,64 End 0,79
F7 0,65 PgUp 0,73
F8 0,66 PgDn 0,81
F9 0,67 Ins 0,82
F10 0,68 Del 0,83
Here are some sample ANSI sequences!
Escape Codes Meaning to ANSI.SYS
------------ -------------------
^[[4;0;61p F3 -> Ctrl-D
^[[5;0;62p F4 -> Ctrl-E
^[[19;0;77p Right Arrow -> Ctrl-S
^[[1;0;75p Left Arrow -> Ctrl-A
With these kinds of mappings, almost any program should be able to run,
if it uses the DOS handles for standard input and output. This should
make the "Shell to DOS" quite useful.
32
Setting up for Power-Loss-Protected GT Host Mode Operation
It is quite easy to prepare a set of files that will allow you to bring
GT POWER up into what I should like to call a Power-Loss-Protected
Host Mode of operation. First, however, a few concepts:
Whenever power is first applied to your system, (or re-applied following
a blackout), the system will boot your DOS into memory and that, in
turn, will look for two files; CONFIG.SYS and AUTOEXEC.BAT. Finding the
CONFIG.SYS, the DOS will tailor your environment according to its
contents (such as setting a new maximum number of files and file
buffers). Finding the AUTOEXEC.BAT file will cause the system to
immediately execute the set of DOS instructions found therein.
GT POWER may be caused to run in an unattended Host mode either
through GT commands entered at the keyboard (Alt-dash) or via script.
The GT command to do so in a GT script is simply: HOST.
GT POWER has a built-in 'Watchdog' function that causes a system
reset (the equivalent of a re-boot) under the following condition: It is
in Host mode and a user has invoked the Shell to DOS function and
Carrier Detect is lost while in the DOS Shell (door).
Given the above, to set up the system for Power-Loss_Protected Host mode
operation of GT POWER you must construct the following files:
Your normal AUTOEXEC.BAT
A copy of the normal AUTOEXEC.BAT called AUTOEXEC.OLD
A new file called AUTOEXEC.GT
A new file called HOST.BAT
A GT script file called HOST.SCR
The first four of these files belong in your root directory while the
script file should be placed in the same directory as GT POWER
resides. When you want to enter the Power-Loss-Protected Host mode of
GT POWER you need only type the single word HOST from any directory.
The result will be the invoking of the HOST.BAT file which, in turn,
copies the AUTOEXEC.GT file on top of your normal AUTOEXEC.BAT (so that
if a re-boot occurs it will get control), it then sets a default
directory so that your private directories are not accessible to callers
into the system, and then it invokes GT POWER specifying the name
and location of the HOST.SCR script file you created. Thus, GT will be
given control and placed into Host mode. Upon normal termination, GT
exits to DOS which returns to the unexecuted portion of the HOST.BAT
file and continues by doing a copy of AUTOEXEC.OLD (a copy of your
original AUTOEXEC.BAT) on top of the current one and ending.
In the event of a power failure while in Host mode, or loss of carrier
while in the DOS Shell, the AUTOEXEC.BAT file that is in place will
reset to the default (safe) drive and reinvoke the Host mode of GT
POWER.
33
Sample files for Power-Loss-Protected Host Mode operation
Original AUTOEXEC.BAT (and AUTOEXEC.OLD!!):
Echo off
Ver
Prompt $p$g
Path = C:\DOS;C:\;C:\COMM;C:\FREEWARE
Set GTPATH=C:\COMM
AUTOEXEC.GT:
Echo off
Ver
Prompt $p$g
Path = C:\DOS;C:\;C:\COMM;C:\FREEWARE
Set GTPATH=C:\COMM
D:
CD \EMPTY
GT1200 C:\COMM\HOST.SCR
C:
CD \
COPY AUTOEXEC.OLD AUTOEXEC.BAT
HOST.BAT:
Echo off
Copy C:\AUTOEXEC.GT C:\AUTOEXEC.BAT
CLS
D:
CD \EMPTY
GT1200 C:\COMM\HOST.SCR
C:
CD \
COPY AUTOEXEC.OLD AUTOEXEC.BAT
CLS
HOST.SCR:
HOST
That's all there is to it.
34
Running GT POWER under DESQview(tm)
GT POWER runs quite well as a task under the DESQview(tm) multi-tasking
system. There are a few things that should be kept in mind when doing
so, however.
For example, in order to prevent any 'bleeding' of your GT screens into
another task, you must set the BIOS parameter of GT to TRUE. Note that
the effect of doing so totally eliminates any use of direct screen
writes by GT and that it will substantially increase the time it takes
GT to 'open' a window. It does not affect any other function of GT nor
does it affect any other aspect of GT performance.
Also, you will need to provide enough memory for GT to run while under
DESQview(tm). If you do not have to consider KERMIT or ZMODEM then
you can run GT in a partition of as small as 330K of RAM.
Experimentation has shown that in order to support ZMODEM and the other
protocols mentioned above you will need to set the partition size to
440K.
GT, as it requires rapid access to the serial port you are using for
communications must be the first task loaded in DESQview(tm). And, a
performance option of DESQview(tm) (set by invoking the SETUP program)
must be set showing the existence of High Speed Communications. Other
options that need to be set include the fact that GT is NOT SWAPPABLE to
disk and time slices somewhere between 3 and 6 ticks in length per
partition.
(tm) DESQview is the trademark of QuarterDeck Office Systems.
- THE END -
35